Webhosting organizations often manage extensive operations, hosting thousands, tens of thousands and even a hundred thousand or more website customers on a single server or collection of servers. Performance and security issues require close attention so that the widest available access is offered to content, while maintaining adequate security of each customer's data.
The level and type of security required when only serving static content (e.g., .html, .jpeg) is quite different from the security that must be applied when serving dynamic content (e.g., executables, scripts). In addition to preventing website visitors from viewing content to which access is restricted (e.g., password-protected pages), it is necessary to further restrict dynamic content so that one customer's scripts (or other executable content processed within a shared server environment) are unable to access another customer's data stored within the same environment.
For example, if only static content is permitted, and all visitors are authorized to view all hosted content (e.g., no customers employ logon schemes to filter access), then security needs are relatively uniform and basic. However, when scripts and/or executable images are permitted to run within a shared web server environment, the range of actions a customer can instruct the web server to perform on its behalf increases significantly. In particular, a customer's scripts may maliciously or accidentally (e.g., through poor programming) damage, destroy or otherwise illicitly access another customer's data.
But, if security restrictions are too stringent, access to a particular piece of content may be mistakenly prohibited, access to authorized content may be delayed, management of the server and the content may become very complex because of onerous security considerations, and so on. The result is an ineffectual web hosting solution that does not adequately serve the needs of customers.
Even while adequate security measures must be enforced to protect each customer's data from other customers, the ability to automatically and anonymously logon web site visitors should be maintained. This allows them to anonymously interact with web site content without the inconvenience of first obtaining logon credentials from a centralized authority (e.g., a username and password, a digital certificate). More specifically, it is beneficial and desirable to give anonymous access to visitors while allowing customer's scripts to be run on the visitors' behalf behind the scenes.
Existing attempts to secure a web server while still allowing automatic and anonymous logons are inadequate or ineffective, especially if dynamic content (e.g., scripts) is served. For example, in many webhosting environments, all anonymous content viewers are automatically logged into the web server using the same server account, regardless of the content they are accessing (e.g., a static web page, an image, a script, an executable). This type of solution does not solve the problem of trying to restrict access to one customer's data from another customer's scripts.
When all anonymous web site visitors share one account, they share one security context and there is no inherent or easy way to differentiate one visitor from another. Therefore, a fileserver, the web server or other arbiter of access to stored data cannot readily differentiate between who should be allowed and who should not be allowed access to a given content file. Unless all visitors (and all scripts that run as a result of a page view) are to have access to all content, individual customers (or other involved entities) will generally have to assign (and distribute) user accounts in order to implement logon procedures for accessing protected content.
More specifically, if executable content (e.g., scripts, executables) is served on a web server, security must be configured robustly to prevent unauthorized access to stored data, but without sacrificing acceptable performance. Part of the security requirement entails a need to separate or segregate customers and their data, so that dynamic content from one customer cannot be used to access another customer's protected data.
For example, one customer could author a script that attempts to delete all files on the web server, all files within another customer's directory structure, or cause some other mischief. Solutions to this problem are complicated by the need to allow viewers of customer content to connect anonymously and automatically.
Some middleware or application-level software attempts to supply safeguards against unauthorized access by users of that software. For example, PHP (PHP Hypertext Processor) includes a safe-mode of operation that attempts to reduce the ability of an anonymous content viewer or user to cause damage when running a PHP script. But, like virtually all application-level software, it has holes that can be exploited.
Another solution to the need for a security scheme to safely allow dynamic content to be served without drastically impacting performance involves the use of virtual machines. In this scheme, a virtual machine or virtual server is constructed for each customer on the server. This solution is processor-intensive because of the need to establish many virtual environments, and can be very expensive because resources must be licensed on each virtual machine. Further, some mapping resource would have to be employed to map content viewers to the correct customer's virtual machine.
IIS (Internet Information Services) by Microsoft® includes an associated metabase that maps statically coded URLs (Uniform Resource Locator)—corresponding to content that viewers may request—to a particular user account to apply to each request. However, a metabase is limited in capacity (i.e., how many mappings it can store) and cannot scale to support a web server that may serve content from tens of thousands or hundreds of thousands of websites.
If multiple web servers and metabases were to be implemented in order to host a large number of web sites, further complications would arise. Because a metabase has limited capacity, supporting a number of sites greater than one metabase's capacity requires content requests to be pre-processed. Pre-processing causes each request to be directed to the correct server (i.e., the server with the metabase corresponding to the requested web site).
Because redundancy in serving web sites is desirable, each metabase would be replicated among a pool of servers to provide failover protection. This can make sharing metabases challenging, especially when the hosted web sites are dynamic—meaning that they change at the whim of the customers, perhaps to modify their naming criteria, remove a web service, etc.
Solutions that result in duplication of data without adequate tools for managing replication of that data have proven to be expensive and prone to error. Further expense is incurred when providing servers to support groups of distinct metabases rather than a single metabase.
Another problem with supporting anonymous access to content on a web server is the burden of repeatedly contacting a domain controller (or other authentication entity) to authenticate each virtual viewer session (e.g., to logon each request to a default anonymous user account). This burden can cause performance degradation not only in the web server, but also in a filer that accepts SMB (Server Message Block) network logons associated with a web server logon session.
Caching anonymous logon sessions on the web server typically is not feasible, especially if viewer requests for content are distributed among multiple processes, because a logon handle or context is only valid, by default, in the process in which it loaded. Requests may be distributed among multiple processes to help prevent one customer's malicious or faulty script from adversely affecting the run-time experience of other viewers. Existing logon caching schemes do not allow inter-process communication to permit the sharing of logon handles, and the overhead of establishing separate caching schemes for every process would yield little or no overall benefit.